Add-on: The NPC Editor

game developmentgodotmoonwards

I’ve been a developer at Moonwards for 2 years now and though I’ve had many roles and done many things, from debugging, refactoring code, networking, fixing materials and more, lately I’m the NPCs and tools guy. I made the Dialog system (and its editor), the Workstations and Navigation system and most importantly, the NPC Editor - and the NPCs that use it. The editor has been a constantly evolving idea. It began as a simple interpretation of a Bungie Publications’ presentation that talked about Halo 3’s behavior trees. Later on...

I’ve been a developer at Moonwards for 2 years now and though I’ve had many roles and done many things, from debugging, refactoring code, networking, fixing materials and more, lately I’m the NPCs and tools guy. I made the Dialog system (and its editor), the Workstations and Navigation system and most importantly, the NPC Editor - and the NPCs that use it.

The editor has been a constantly evolving idea. It began as a simple interpretation of a Bungie Publications’ presentation that talked about Halo 3’s behavior trees. Later on, I learnt about State Machines and found out these two concepts could mix pretty well.

The current concept

The NPC Editor creates State Machines and Behavior trees. The resulting NPC is a “State Machine” where every state is a different Behavior Tree. The concepts of “Stimulus” (Signals), “Inhibitors” (functions with returns) and “Actions” (functions without returns) are the main components of the Behavior Tree. The Behaviors and extra information, like the character’s name and colors, are stored in the State Machine.

To modify the signals and functions available to the tool, one has to modify the Definitions.gd file and create a script that extends NPCBase and contains your custom functions. Even if the files generated by this tool are intended to be used inside Godot, they are not specific to the engine and could be used in Unity, Unreal Engine or a custom engine (with slight modifications to use their filesystem).

What’s left to be done?

As it currently stands, the State Machine that uses the NPC doesn’t change states in a particular, predictable order, and though that is the desired behavior for now, I plan to implement a way to specify which state or set of states loads next. The addon currently depends on having cohesion on the programmers side: all the nodes defined in a special file (Definitions.gd) should have a function of the same name in a custom NPC Script that extends NPCBase. Ideally, the Definitions would be created at load, using the functions in the custom NPC script. Currently there’s only support for the first input slot of a GraphNode, soon I’ll implement a way to set and get the NPC’s variables inside the Behavior Tree editor, so these can be used in other input slots. There’s plenty of room for optimization, as many parts of the NPCBase could benefit from GDNative’s speed or using a different approach from signals and connections. You can read more about the development process here.